home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9701 / 000005_owner-linux-arm…r.rutgers.edu _Sun Jan 19 23:16:19 1997.msg < prev    next >
Internet Message Format  |  1998-01-25  |  3KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id XAA26575 for <willy@odie.fluff.org>; Sun, 19 Jan 1997 23:16:19 GMT
  3. Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68365-8831>; Mon, 20 Jan 1997 01:16:40 +0200
  4. Received: by vger.rutgers.edu id <213035-11748>; Sun, 19 Jan 1997 18:06:35 -0500
  5. Date:     Sun, 19 Jan 1997 23:15:25 +0000 (GMT)
  6. From: Philip Blundell <pjb27@cam.ac.uk>
  7. X-Sender: pjb27@hammer.thor.cam.ac.uk
  8. To: Charles Esson <charlese@cvs.com.au>
  9. cc: linux-arm@vger.rutgers.edu
  10. Subject: Re: Arm Linux
  11. In-Reply-To: <32E2A04B.225C@cvs.com.au>
  12. Message-ID: <Pine.SOL.3.95.970119230311.7848A-100000@hammer.thor.cam.ac.uk>
  13. MIME-Version: 1.0
  14. Content-Type: TEXT/PLAIN; charset=ISO-8859-1
  15. Content-Transfer-Encoding: 8BIT
  16. Sender: owner-linux-arm@vger.rutgers.edu
  17. Precedence: bulk
  18. Status: RO
  19.  
  20. On Mon, 20 Jan 1997, Charles Esson wrote:
  21.  
  22. > I slept on it last night and concluded this has just got to happen. The
  23. > strong-arm is a great chip, 0.5 watts, 220 mips. This is just unheard of
  24. > performance and opens up so many possibilities, further the Arm
  25.  
  26. That's true.
  27.  
  28. > -Merge with Linus source tree, obviously no.
  29.  
  30. No, that will have to be Russell really. 
  31.  
  32. > -gcc If the problem is translation of the intermediate code to
  33. > assembler, perhaps. If the problem is the compiler itself, no it would
  34. > require specialized knowledge that I don't have and are unwilling to
  35. > learn. This however is something we could live with in the short term
  36.  
  37. Yes.  I'm not too keen on digging around in the compiler myself really -
  38. compilers aren't exactly my area of interest.  As you say, it can wait;
  39. it's good enough for now. 
  40.  
  41. > -ELF. To my mind if the kernel is up and running  then this is the next
  42. > cab of the rank, and I will put up my hand. I have this horrible feeling
  43. > however that this will involve mods to the gcc backend.
  44.  
  45. Yes.  This will probably need changes to gcc and binutils.  However, it's
  46. not just a Linux problem and we might be able to liase with the NetBSD
  47. people.  Ditto with X, actually. 
  48.  
  49. > -glibc, or libc.so.6. If someone else wants to do the ELF stuff, I will
  50. > put up my hand for this one, but as I understand it, one of the
  51. > advantages of ELF is the simplification of library support, making ELF
  52. > the first problem.  
  53.  
  54. Yes.  glibc is something I'd envisaged doing myself, but I'm always keen
  55. for other people to help.  ELF isn't a prerequisite to _start_ the work,
  56. but it will be required sooner rather than later. 
  57.  
  58. > Well that�s about where I sit, the biggest problem I see is that someone
  59. > has to organize who does what so there isn�t a duplication of effort,
  60. > and we have to move to a team approach so the job gets done.
  61.  
  62. Quite.  I'm quite prepared to keep track of who's doing what.  There seem
  63. to be precious few people who _are_ prepared to do any programming, so I
  64. don't imagine it will be too arduous. 
  65.  
  66. phil